Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/appleip/appleip-minutes-90july.txt

Text File | 1993-02-17 | 11KB | 260 lines

CURRENT_MEETING_REPORT_


Reported by Bob Morgan/Stanford

APPLEIP Minutes

IP-in-DDP

John Veizades led a discussion of his draft RFC for IP-in-DDP. These
issues were discussed:


   o The use of the name ``MacIP'' for this protocol was criticized.
     People are encouraged to think of a new name.
   o There was agreement that gateways should never do proxy ARP replies
     to NBP ARPs.  In fact, clients are discouraged from doing NBP ARPs
     at all unless they have reason to believe that the destination is
     on the same AppleTalk internet.  Clever clients can do NBP ARPs to
     optimize communication in this admittedly rare case.  The user will
     probably have to specify the zone in which to do the NBP lookup in
     this case.
   o Clients must be prepared to get responses from multiple gateways.
   o The dotted decimal format for IP addresses used in NBP lookups must
     be better specified.  Text might be borrowed from an existing RFC.
   o Gateways currently send regular NBP confirms to their IP clients to
     determine whether the IP address is still in use.  Gateways should
     try to minimize the bandwidth used for this, perhaps by only doing
     confirms when they are running short of IP client addresses.
   o It was proposed that gateways should be able to be configured with
     a list of acceptable zones in which to do NBP ARPs.  This should
     help to prevent duplicate IP address assignment, and let gateways
     and users search the entire ``subnet'' more easily when necessary.
   o There could be a CEASE ATP message from gateway to client to tell
     the client to stop using an IP address (useful in case of duplicate
     assignment).  There could also be a REDIRECT message from gateway
     to client, similar to ICMP redirects.
   o It was suggested that gateways should have throttles on the rate at
     which they forward NBP lookups, to prevent clients from flooding
     internetworks with broadcasts.  LBL has a working implementation.
     Apple suggested that System 7.0 will improve Macintosh client
     behavior in this area.
   o The gateway's ATP response to a client ASSIGN request should be
     able to contain more information.  It was proposed to define or
     redefine some of the response fields.  The new format will be
     distinguished by putting a version number in the first 16 bits of
     the ATP User Data area.  The second 16 bits must be zero.  The
     first version to be defined will be version 1.  New field uses:
     The ``Other #1'' field is redefined to be the subnet mask.
     The ``Other #2'' field is defined as a time server address.
     Some implementors are already using some of the ``Other'' fields
     for their own purposes.  They will report on these to the RFC
     author.

                                   1






   o Gateway implementors should report any error codes that they send
     in ATP responses to the RFC author, who will compile a generic
     list.
   o A new ATP REGISTER STATIC request should be defined to allow
     clients with static IP addresses to register them with the server
     and get any useful response information.  The client will put the
     static address into the ``Assigned IP address'' field.  Gateways
     should do a sanity check on the address and send an error response
     if necessary.
   o Several changes were suggested to the draft RFC. Among them:

      -  Drop references to Macintosh.
      -  Drop AARP definition.
      -  Drop the line ``The IP address used by a gateway with multiple
         IP addresses is the address that is responded to using the NBP
         ARP.''
      -  Hosts do not use ATP XO requests, but ATP ALO.
      -  The line ``There is no response to a RELEASE packet'' should be
         ``The ATP response to a RELEASE request is empty''.
      -  Drop the suggestion to limit IP-in-DDP datagrams to 576 octets.
      -  Drop Step 3 in the sample transaction stream.


MIB

A draft MIB, written by Steve Waldbusser of CMU, was distributed.
People found it generally acceptable.  There was concern that it be
clearly labelled as an ``AppleTalk-IP gateway MIB'' and not an
``AppleTalk MIB''.

It was noted that there is no AppleTalk-in-PPP MIB. Frank Slaughter from
Shiva , who is working on AppleTalk-in-PPP, and Steve Waldbusser will
work together on this.

It was suggested that the rtmpNextHop variable be extended with a Type
string to distinguish between different protocol transports such as IP,
DECnet, OSI, etc.

AppleTalk-in-UDP

Allan Oppenheimer from Apple led a discussion of wide-area networking
using AppleTalk encapsulated in UDP/IP. The general idea is to connect
existing AppleTalk internets via the IP Internet.  There are a number of
issues:


   o Can/should a world-wide AppleTalk Internet be created using the
     facilities of the existing IP Internet?
   o How much administration within a site is necessary/acceptable?  How
     much coordination between pairs of sites, or between all sites, is
     necessary/acceptable?
   o Is administrative control of routing necessary for security

                                   2






     purposes, or is plug-and-play more crucial?
   o Can the existing DDP-in-UDP encapsulation meet the need, or are
     changes required?
   o Can all AppleTalk-based applications be supported?  Is a subset
     such as LaserWriter printing and AppleShare file service
     acceptable/easier?
   o Are there solutions to network number scaling and clashes?  Are
     there solutions to zone name scaling and clashes?
   o Is it important that hosts be able to communicate directly in this
     internet using the standard encapsulation, or is communication
     through routers sufficient?


Van Jacobson from LBL described a scheme that addresses some of these
issues.  He has impemented this method on software running on FastPaths
at LBL and some other sites.

In Jacobson's scheme, each site maintains a table with one entry for
each external AppleTalk network with which it wishes to communicate.
Each entry in the table contains three fields.  The first is the real
16-bit AppleTalk network number of an AppleTalk network at a remote
site.  The second is a 24-bit IP network number that is associated
one-to-one with the previous AppleTalk network number.  The third is a
16-bit AppleTalk network number which is used to identify the remote
network within the local AppleTalk internet.  The first two numbers form
a pair that a site can give to any other site with which it wishes to
communicate.

The table is distributed to some number of routers in the local
AppleTalk internet that are running software that understands this
scheme.  Not all routers in the local internet are required to run this
software.

When a participating router receives a datagram to be forwarded, it
looks up the destination network number in its mapping table.  If the
number matches an entry (using the third field as described above), the
router proceeds to encapsulate the datagram in the standard DDP-in-UDP
encapsulation used by KIP and CAP for transmission across the IP
Internet.  The router forms the destination IP address by using the IP
network number from the table entry and the 8-bit DDP node number.  The
router also inserts the ``real'' AppleTalk network number from the table
into the destination network field in the DDP datagram.  It then
transmits the IP datagram.

The datagram proceeds across the IP Internet to a router at the remote
site.  This router has been advertised as a router for the IP network
which is associated with the destination AppleTalk network, so the
datagram goes to it.  Somehow this router inserts the appropriate
AppleTalk network number into the source network part of the DDP header
[I DON'T KNOW HOW IT DOES THIS] and forwards the datagram to the
destination AppleTalk network through the local internet.



                                   3






This scheme has these advantages:


   o It uses the existing DDP-in-UDP encapsulation.
   o In order for two sites to communicate, each site has to manually
     enter the other's networks of interest into its mapping table.
     This provides desirable administrative control.
   o By inspecting source IP addresses, a host using DDP-in-UDP (eg CAP)
     can communicate directly with another DDP-in-UDP host, without
     requiring routers, after the first few datagrams.
   o Each site can have up to 64K (minus the number of internal
     AppleTalk networks) remote networks with which it can communicate.
     Since communities of interest will vary, the entire meta-internet
     can have many more than 64K networks.
   o There is a working implementation.


People thought that Jacobson's scheme was very interesting and deserving
of more study.

After this discussion, Phil Budne of Shiva volunteered to write a draft
RFC describing the current practice of DDP-in-UDP encapsulation.

KIP and Phase II

Karen Frisa from Novell sent to the Apple-IP mailing list a draft
proposal for extending the KIP routing and zone information protocols to
handle AppleTalk Phase II. There wasn't time to discuss this proposal at
this meeting .

Next Meeting

John Veizades proposed that this Working Group have another meeting
before the December IETF plenary.  A time in the vicinity of the October
INTEROP conference was suggested.

Attendees


Philip Budne             [e-mail]
Cyrus Chow               [e-mail]
Steve Deering            [e-mail]
Robert Elz               [e-mail]
Tom Evans                [e-mail]
Alf Farnham              [e-mail]
Karen Frisa              [e-mail]
Peter Harrison           [e-mail]
Van Jacobson             [e-mail]
Holly Knight             [e-mail]
Sam Lam
Olivier Martin           [e-mail]
Milo Medin               [e-mail]

                                   4






Robert Morgan            [e-mail]
Rebecca Nitzan           [e-mail]
Zbigniew Opalka          [e-mail]
Allan Oppenheimer
Brad Parker              [e-mail]
Michael Roberts          [e-mail]
Gregory Vaudreuil        [e-mail]
Steve Waldbusser         [e-mail]
Jonathan Wenocur         [e-mail]
Steve Willis             [e-mail]
Allan Young              [e-mail]



                                   5